-
Notifications
You must be signed in to change notification settings - Fork 2
Implement Multi-Threading into CARP #24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Some notes:
Again, this is a bit pedantic of me, but it allows for the program flow to be a bit more natural imo. You can ignore this if you like, I may add them in in the future to understand where and what is happening throughout the code :) I'll get to actually reviewing the code as soon as I can 😅 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lovely bit of code, improving CARP immensely! Very easy to read as well, other than a few minor caveats. I'm happy for this to be approved after the caveats are addressed.
My prior comment on documentation can wait I think (in part because its hypocritical, I'd forgotten how badly I documented the functions myself 🤦♂️), I'll add general documentation of functions as an issue and add it into the technical debt (#26). Thanks again for writing this. 😸
|
Looks good! In lieu of actual tests I think it would be nice that we double check that the code works in the lab (we can do this together or I can do it, whatevers easier), then I'll approve the PR and we can get to rebasing and merging. |
jwaiton
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR introduces multi-threading into CARP to deal with the high throughput needed for acquisition purposes. The docstrings and documentation is being left for a later date.
Great job! Lets rebase it and get it merged 😸
All digitiser function calls have been replaced with pushing commands to a thread safe command buffer.
Added local flags to keep track of digitiser status. Replaced digitiser member function calls with controller member function calls. Controller member functions interface with digitiser via a thread-safe buffer.
CARP is now multi-threaded. The PyQt GUI and the controller class (which interfaces with the GUI) sit on the main thread. Now, the AcquisitionWorker class is instantiated on its own thread. Let's call this thread the worker thread. The main thread and worker thread communicate with one another via two thread safe buffers. One buffer is for commands being sent from the GUI on the main thread to the digitiser on the worker thread. The other buffer is for data sent from the worker thread to the main thread that is to be displayed on the GUI. The data structure used for these buffers is a python Queue as it is thread safe by default.